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@ An apparatus and method for a federated naming system which can resolve a composite name 
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@ In a distributed computing environment, an apparatus and method for a federated Naming System 
which can resolve Composite Names comprised of Names from an arbitrary number of disparate 
Naming Systems. A syntax for Composite Names is defined as well as necessary operations to directly 
resolve such Composite Names without the need for customized agents or gateways. 
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BACKGROUND OF THE INVE^^■|ON 

1. TECHNICAL FIELD 

5 This invention relates to Object-Based Distributed Computing Systems, and more particularly to the field 

of naming systems. 

2. DESCRIPTION OF RELATED ART AND BACKGROUND 

10 A portion of the disclosure of this patent document contains material which is subject to Copyright protec- 

tion. The Copyright owner has no objection to the facsimile reprwJuction by anyone of the patent disclosure 
itself, as it appears in the Patent and Trademark Office patent files and records, but otherwise reserves all 
Copyright rights whatsoever, including specif icaliy all rights to any other copies of all or part of any computer 
progranns which may be disclosed herein. 
15 A fundamental facility in any computing system is the Naming Service (the "Naming Service"). A Naming 

Service is the means by which names are associated with objects, and by which objects are found given only 
their names. A Name ("Name") is a sequence of one or more atomic names, where an atomic name ("Atomic 
Name") is a name defined by a naming convention which, for example, may be a sequence of one or more 
characters. For example. "user/John.Smith/foo" is a Name and "user". "John.Smith", and "foo" are Atomic 
20 Names. An object ("Object") is generally a combination of data and operators or operational routines related 
to that data. Naming Services usually provide operations for 
associating, or binding, names to objects 
finding the objects bound to given names 
removing name association or bindings 
25 querying, renaming, etc. 

In early versions of computing systems, the naming schemes used were not the result of well defined nam- 
ing services but rather an incidental set of rules for naming things created by the system designer. Over the 
past decade more systenr^tic and formal approaches to the development of computer systems designs have 
led to the creation of discrete or standalone computer services such as. f i!e systems, directory services, da- 
30 tabases. etc. Each of these services, in n^ny cases, have created their own set of rules for naming Objects 
within the service, and for use by clients. 

Most of the early Naming Services did not communicate with each other. Clients had to use the services 
separately. In those rare cases where such services had to be used together, communication was by means 
of a "Composite Name". A "Composite Name" is a sequence of names from more than one Naming System. 
35 In today's UNIX'* systems (UNIX is a registered trademark of AT&T), certain applications, such as "mount" and 
"rep", implement resolution of Composite Names with components from different naming systems. To do this, 
these applications may use a special delimiter character to separate Names in the Composite Name, enabling 
them to resoh/e the Composite Name to the corresponding Object by using each component naming system. 
Unfortunately, the use of such Composite Names is limited to the small set of applications that are able to 
40 resolve them. Also, such applications are typically restricted to only a small and fixed number of Naming Sys- 
tems. Adding a new type of Naming System would require all of the applications to be changed. 

A serious problem with the use of Composite Names today is the lack of uniformity and transparency. The 
user must be aware of which commands accept Composite Names, and their required syntax. For example, 
the composite name "sylvan :/temp/foo" is acceptable to the UNIX command "rep", but it is not accepted by the 
4S command "cp". 

More recently, the increased use of computers in business and at home, due to reduced costs and in- 
creased computer literacy, has led to increased demand for access between computer systerrts. Portable com- 
puters allow users to move them freely about the world but these users continue to require constant access 
to their host applications, files, databases and electronic mail via connections to other computer systems. New 

50 networks of computers reiquire more access to more and more disparate networks and related systems. These 
increasing demands have produced the present focus on Distributed Computer Systems and on methods to 
interoperate these systems. This focus on interoperability is on developing means for easy access from one 
computing system to another, regardless of whether t he two systems have different naming systems, different 
operating systems, different file systems, different databases, etc., with minimal cost of modifying any system 

55 to interoperate with another. 

Moreover, widespread deployment of f ibensptic communication lines, together with high speed packet- 
switching technologies, are greatly increasing the capacity and performance of wide-area networks. These 
advances, coupled with new object-based technologies, create a tremendous need for systems and methods 
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which will allow systems to communicate with each other efficiently. 

A major stumbling block In developing such easy access between systems Is the disparate naming con- 
ventions and naming operations used by the various individual file systems, databases, operating systems, 
communications systems, etc. 
5 Several approaches have been and are being developed to address this problem of dealing with disparate 

naming systems. An approach for handling Composite Names is provided by the Open Software Founda- 
tions/Distributed Computing Environment (the "OSF/DCE"). Open Software Foundation fOSF") is a trade- 
mark of Open Software Foundation, Inc. 

The OSF/DCE approach to this problem of handling the existing disparate naming systems is through the 
10 use of Composite Names. 

OSF/DCE provides a method of handling composite names composed of three levels of naming systems: 
1) the global directory service, either CCITTs X500 or Internet's Domain Naming Service ("DNS") that names 
cells; 2) the OSF/DCE Cell Directory Service ("CDS") that names users, file servers, databases, and other 
servers in a cell; and 3) the naming system of OSPs Distributed File System ("DFS") and other services named 
15 by CDS. 

For example, the following is a Composite Name handled by OSF/DCE, 
7.../C=US/0=OSF/OU=Cambridge/fs/user/John.Smith/foo" 
where 

/ = name of the local computer host's root 

20 ... = name of the global root 

C=US/0=OSF/OU=Cambridge = X.500 name of a cell root 
fs = CDS name of the DFS root 

user/Jo hn.Sm It h/foo = DFS UNIX file name. 

This approach of OSF/DCE permits Composite Names spanning two or three Naming Systems (three in 

25 the above example), and provides a significant advance In handling disparate Naming Systems. However, this 
approach uses agents that are customized to specific naming systems. This method lacks the flexibility and 
scalability that will be required by Object-Based distributed systems in the future. A change to one of OSF- 
/DCE's Naming Systenris, or the addition of a new type of Naming System requires changes to existing agents 
or the addition of a new customized agent Also, the future need will be to support Composite Names that span 

30 an arbitrary number of Naming Systems, not just a fixed number such as two or three Naming Systems. 

At present, the development of Object-Based Distributed Systems has just begun and the expected pro- 
liferation of such systems and the corresponding increase in the number and type of "Objects" requiring 
"Names" and Name resolution makes the development of efficient and flexible Naming Systems of paramount 
importance. 

35 Accordingly, the present invention defines a model which can describe any Naming System and Its related 

characteristics, defines a method of federating an arbitrary number of disparate Naming Systems with minimal 
computing cost and effort to participate In the federation, and defines an apparatus and method for using this 
federated Naming System to perform the functions of name resolution in an Object- Based Distributed Conv 
puting Environment. It is noted that existing Naming Systems which are not Object-Based may be able to par- 

40 ticipate in a federated system such as is disclosed herein, but only at some expense through the use of cus- 
tomized gateways. 

The prior art does not define Naming Systems for Composite Name resolution in a federatbn of an arbitrary 
number of disparate Naming Systems. 

45 SUMMARY OF THE INVENTION 

Goals of the present invention are to: 

- Provide Clients with a single uniform Composite Name resolution interface to a Federated Naming Sys- 
tem; 

50 - Allow an autonomous Naming System to participate in the federation with minimal cost and effort and 

with no impact on existing Naming Systems; 

- Provide a system which allows the addition of new services with their own Naming Systems without re- 
quiring changes to Clients or to other existing Naming Systems In the Federation; 

- Provide a system which does not require intermediate customized Gateways or customized Agents to 
55 assist in the resolution of Composite Names, thereby resulting in better performance and fewer fault 

tolerance issues. 

To accomplish these goals, the invention provides, in a distributed computing environment, an apparatus 
and method for a Federated Naming System which can resolve Composite Names comprised of Names from 
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an arbitrary number of disparate Naming Systems. In order to join in a federation of Naming Systems, the in- 
dividual Naming Systems are required to have within their systems the means for separating a Name Into a 
•Tiead" Name component and a "tail" Name component as defined herein. The method for doing this resolution 
internally is left to the individual Naming System. Given however, that the individual Naming System has the 

5 required parsing methods, they may then join in the specified federation by implementing a federation syntax 
for Composite Names, and by implementing a Composite Name Lookup operation at a minimum. The invention 
specifies a method and apparatus for implementing such a federation of Naming Systems and for resolving 
Federation Composite Names. 

With this apparatus and method, systems with disparate Naming Systems may easily federate to provide 

10 their individual clients with efficient resolution of Composite Names of Objects located in other systems. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Figure 1 is depiction of a Naming System in the prior art 
15 Figure 2 Is a representation of a Federated Naming System as described in this disclosure. 

DETAILED DESCRIPTIOM OF THE IWVEmiOM 

An Apparatus and Method are disclosed which provides an efficient name resolution system for a feder- 
20 ation of any number of disparate Naming Systems in an Object-Based Distributed Computing Environment A 
model of a Naming System is described which can define the characteristics of any Naming System. Within 
the context of this Naming System model, a method for federating any number of disparate Naming Systems 
is described, including an apparatus and method for name resolution of a Composite Name composed of any 
number of such discrete Naming Systems. 

25 

WAR/aMG MODEL 

The following object-based model defines Naming Systems In at>stract terms. 
A "Name" is a sequence of one or more atomic names. 

30 An "Atomic Name" is a value specified by a naming convention, which, for example, could be a sequence of 
one or more characters. Every Name is defined by a "Naming Convention" which is a set of syntactic rules 
which govern the form of a Name. A naming convention defines alt possible Atomic Names and enables the 
definition of operations for parsing any Name to produce its sequence of Atomic Names. The naming conven- 
tion also enables the definition of a relation for determining if two Names are equivalent 

35 The two basic name parsing operations are, "head(Name)" that returns the first atomic component of "Name", 
and "tall(Name)" that returns the remainder of "Name" after "head(Name)" is removed. For example, in parsing 
the name "user/John. Smith/foo" the operation "head (user/John.Smith/foo)" would return "user" (assuming 
"user" is defined as the "head" by the particular naming convention); and the operation 
nail(user/John.Smlth/foo)" would return "John.Smith/foo". 

40 A "Name Space" is the set of all possible Names generated according to a naming convention. 
A "Binding" is an association of an Atomic Name with an Object reference. 
An "Object Reference" is an address or device used to invoke operations on an Object. 
A "Context" is an Object whose state is a set of bindings with distinct Atomic Names. Every Context type has 
an associated Naming convention. 

45 A Binding can associate any type of object to an Atomic Name. Thus a Context can contain bindings of Atomic 
Names to other Contexts. In this way, file systems and directory services are hierarchically stuctured. 
The naming operations provided by a Context include "Lookup". "Bind", "UnBind". "Ust", and "CreateContext^. 
These are defined as follows for a Context denoted "c". a Name denoted "n", an Atomic Name denoted "an", 
and an Object reference denoted "s". 

50 An invocation of "c.LookUp{n)" is evaluated as follows: Let "s" be the Object reference bound to "head(n) in "c". 
If "n" is an Atomic Name, then return "s". Otherwise, return "s.LookUp(taa(n))". For example, referring now to 
Figure 1. we shall describe how this operation "c.LookUp(n)" would work in an example using an existing Nam- 
ing System. Figure 1 depicts a Naming System X of a type that can be found in the prior art Naming System 
X220 

55 contains Context Objects 100. 110. 120, 130, 140, 150. and 160, and Objects 170, 180. 190, and 200. Context 
100 contains two bindings, "com" 102 to Context Object 120. and "edu" 101 to Context Object 110. Context 
120 contains three bindings, "smcc" 121 to Context Object 130, "suntech" 122 to Context Object 140. and "sun- 
soft" 123 to Context Object 150. Context 150 contains only one binding, "maintenance" 151 to Object 200. To 
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resolve a Name "maintence.sunsoft.com" from Naming System X 220 in Context 100, we invoke on context 
100 the Lookup operation as follows 

context 1 0(>->LookUp(''maintenance.sunsof t.com") 
In Context 100 the following operations are performed: 
5 head("malntenance.sunsoft.com") which returns "com"; and 

tail("maintenance.sunsoftcom") which returns ^ 
"maintenance.sunsoft". 

Since the Context 100 knows that "com" (which was returned by the "head** operation), is bound to a reference 
to Context 120, and since the "tail" operation returned a non-null value (i.e. "maintenance.sunsof t"), the reso- 
10 lution process continues by invoking "LookUp" again but this time relative to Context 120 and with the reduced 
Name "maintenance.sunsoft" that was returned by "tail". So, in context 120 the following operations are per- 
formed: 

head("maintenance.sunsoft") which returns "sunsoft"; and 
tail("maintenance.sunsoft") which returns "maintenance". 
15 Since the Context 120 knows that "sunsoft" (which was returned by the "head" operation), is bound to a ref- 
erence to Context 150, and since the "tail" operation returned a non-null value (i.e. "maintenance"), the reso- 
lution process continues by invoking "LookUp" again but this time relative to Context 150 and with the reduced 
Name returned by "tail". So, in Context 150 the following operations are performed; 
head("maintenance") returns "maintenance"; and 
20 tail("maintenance") returns a null value. 

Since the lail" operation returned a null value the Lookup operation terminates, returning eventually to the 
Client, the reference to Object 200, which Context 150 knows is bound to "maintenance". 
An Invocation of "c.Bind (an,s)" adds the new binding (an,s) to "c". 
An invocatran of "c.UnBind(an)" removes "an's" binding from "c". 
25 An invocatton of "c.List()" returns the set of atomic names bound in "c". 

An invocatbn of "c.CreateContext(an)" creates a new context object "c*", and adds the new binding (an,c') to 

C . V 

A "Naming System" is a set of context objects that can be represented by a directed graph, where each node 

in the graph is a context, and an arc from one node to another indicates the existence of a binding. For example, 
30 an arc from node a to node b indicates the existence of a binding (an,b) in a. A context is called a "Root context" 

if every other Context in the Naming System can be nanr>ed relative to the Root Context Typically, a Naming 

System has a single Root Context. 

It should be obvious from the above model of a Naming System, the model can be used to describe any 

existing Naming System. It should also be noted, however, that existing systems have their own methods for 
35 parsing names In their systems but they may be considered equivalent to the "Lookup" operations described 

in the present invention. The model shall now be extended to include multiple disparate Naming Systems in 

order to describe in detail the present invention and the presently preferred embodiment thereof. 

FEDERATED NAMING SYSTEMS 

40 

A "Federated Naming System" is an aggregation of autonomous Naming Systems that cooperate through 
a standard interface and protocol to implement name resolution for Composite Names. The contexts in a fed- 
erated Naming System can directly resolve Conposite Names without intermediate customized clerks, cus^ 
tomized agents, or customized gateways. Each member of a federated Naming System (i.e. the individual Nanrv 
45 ing Systems) has autonomy in its choice of naming conventions, administrative interfaces (such as security 
regulations, etc) and its particular set of operations for Name resolution. 

Referring now to Figure 2, a Federated Naming System will be described which is representative of the 
type of Federated Naming System defined by the present invention. Figure 2 shows a set of autonomous Nam- 
ing Systems A1 0, B 70, C 72, D 74, and E 76. Naming System A 1 0 consists of Contexts 12, 1 6, and 20; Naming 
50 System B 70 consists of Contexts 24, 28, and 32; Naming System C 72 consists of Contexts 36, 40, and 68; 
Naming System D 74 consists of Context 64; and Naming System E 76 consists of Context 48. 

The following table shows the Name Bindings in each of the Contexts in Figure 2. 
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The Bindings determine the state of each Naming System 10. 70, 72, 74. and 76. The Naming Systenr^ 
are autonomous in that the naming conventions chosen for each Naming System do not depend on any other. 

35 In the example of Figure 2, Naming System A 10 uses Atomic Names ordered right-to-left with corresponding 
Contexts ordered from bottom-to-top. Naming System A 10 also uses the character as a delimiter. Thus, 
the name of Context Object 24 is "[ORG].sunsof t,com". Similarly. In Naming System B 70, the Name of Context 
36 is "os:dct:[USERS]". Naming System B 70 has Naming conventions in which Atomic Names (i.e. "os" 26 
and "dct" 30) are ordered left-to-right corresponding to Contexts from top-to-bottc»n. and uses the character 

40 as a delimiter. In Naming System C 72, the Name of Context 64 is "John.Smith[EQPMT]". Note that 
"John.Smith" 66 is an Atomic Name. In Naming System D 64, Object 58 has the Name "fax" 56. Naming System 
D 74 has a flat Naming System in that all names are Atomic Names. Finally, also note that Object 58 also has 
a name "^ax" 54 in Naming System E 76. 



45 THE PREFERRED ERflBGDiEflEMT 

In the preferred embodiment at this time, a federation of disparate Naming Systems is designated H'he 
OpenFederatlon of Naming Systems" (hereinafter "OpenFederation"). 

In ordo- for a naming system to be a member of the OpenFederatlon of Naming Systems, it must conform 
50 to standards on two fronts. 

The composite Name Syntax 
The naming Interface to the context object 
Coimipositd Name Syntaui 
The OpenFederatlon prescribes a composition syntax for forming Composite Names from component 
55 Names from different Naming Systems. In general, the OpenFederatlon does not specify or restrict the syntax 
of the component Names from the individual Naming Systems. If there is a conflict between the composition 
syntax and the naming convention of an individual Naming System, the conflict is resolved by "escaping" such 
Names. 
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In the preferred embodiment, the syntax of Composite Names is specified using a pseudo-Backus Naur 
Form (BNF) as follows: 

composite_name: (component)* 
component: namingsystemjd_part component^name 
5 namingsystemjd_part: 'f namingsystemjd T 

namingsystemjd: {any char except T}+ 
The Composite Name Is specified by ordering the components In left-to-right order. Resolution in the 
OpenFederation proceeds in this order. Naming System identifiers (namingsystemjds) separate components 
of a Composite Name belonging to different Naming Systems. 
10 The syntax of "component_name" may vary among Naming Systems. For example, a component Name 

from an DNS Naming System is defined by the DNS naming syntax. 
An example of a Composite Name is 

''Idns]eng.sun.com[userljsmith" 
which consists of two components: "[dns]eng.sun.com" and "[userDsmith". 
15 The portions "[dns]" and "[user]" are Naming System identifiers, "eng.sun.com" and "jsmith" are compo- 

nent Names in the respective Naming Systems. 

The Naming System identifiers in Composite Names serve several purposes: (1) as separators between 
successive components, and (2) in some cases as indicators of the syntactic rules for parsing each component. 
Separators between successive components are needed In order to be able to unambiguously separate 
20 two components in Naming Systems with conflicting Name syntaxes. The ability to separate such components 
is necessary to administer the OpenFederation Composite Name resolution scheme at the federation-level 
given that we wish to handle arbitrary component Naming Systems. 

In addition, It is often useful to be able to parse a Name into components without requiring Name resolution. 
A Composite Name syntax with such separators allows this. To allow independence from a specific Name rep- 
25 resentation, in the presently preferred embodiment, OpenFederation prescribes a standard set of operations 
to be used for breaking Composite Names into components. These operations are "Equivalent", 
"Count_Components", "Concatenate", "Split", "Get_Suffix", "Copy", and "Free", all of which are described be- 
low. 

Although a Client can parse a Composite Name into its component Names, in general, clients may not be 
30 able to parse the component Names into Atomic Names. For example, given a name like •[org]uw[dt]alb.c'' taken 
relative to a context "ctx", a client may not be able to break up the component "alb.c" without invoking a parsing 
operation provided by the context object obtained by "ctx, Look Up("[org]uw[dt]")". 

However, certain Naming System identifiers will be indicators of the syntax of the component Naming Sys- 
tem. In the preferred embodiment, OpenFederation will define a bet of well-known Naming System ids that 
35 are reserved for certain common Naming Systenns, like DNS, X.500, and Unix pathnames. Clients will have 
access to certain standard parsing methods for these well-known Naming Systems. Thus clients will be able 
to parse those components of a Name that bear well-known Naming System ids. 
OpenFederation Operations on Composite Names 
In the preferred embodiment,a number of standard operations on Composite Names are implemented for 
40 use by clients and by OpenFederation Context Objects for composing, decomposing, and comparing Names. 
These operations are defined as follows. However, in order to aid in the description of the operations, the fol- 
lowing terms are used to refer to parts of Composite Names: 

A "prefix" of a Composite Name is any ordered subsequence of consecutive components from the begin- 
ning of a Composite Name. 

45 A "suffix" of a Composite Name is any ordered subsequence of consecutive components from the terminal 

end of a composite Name. 
Equivaient 

In the preferred embodiment, an operation "Equivalent" is defined as follows: 
boolean equivalent( IN composite_name_t enamel, IN 
50 composite_name_t cname2 ); 

Usage: rf( equrvalent( enamel, cname2 ) ) ... 
If this predicate returns "true" then, the two names "enamel" and "cname2" are syntactically equivalent. 
The converse is not guaranteed - if the predicate returns "false",the two names may still be equivalent. 

Equivalence of two names is sufficient to guarantee that, relative to anyone context, the two names cannot 
55 refer to different objects. 

In general, without resorting to resolution, only exact equality will assure equivalence - however it may be 
possible in the case of well-known Naming Systenr»s, to determine equivalence accurately without resolution. 
This function is useful whenever the client wants to determine whether a given composite name is syn- 
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tactically the same as another composite name about which it already has information. For example, for c^ch- 
ing which helps improve efficiency. -Equivalent- could be used to check whether a given name is already in 
the cache. 

Other operations implemented for the preferred embodiment are as Follows: 

Cou nt.Comjjonen ts 
integer count_components{ IN composite„name„t cname ); 
Usage: num_comp = count_components( cname ); 
Returns the number of components in a given composite name, ^'cname". 

Concatenato 

compos!te„name_t concatBnate( IN composite_name_t head, IN composite_name_t tafl); 

Usage: head_plus_taU = concatenate! head, tafl ); ^ »k *«n«t«oH hu 

Returns a new composite name consisting of the ordered list of components from "head . followed by 

those in "tail". 

split( IN composite_name_t cname. IN integer i, O U T composite_nameJ head. OUT composite^na- 
me_t taO); 

Usage: split( three„part_name. 2. ahead. &tail ); ^ ^ „. 

Returns the ordered list of "i" components from "cname" in "head", and the rest ordered in "tail . 
This procedure is useful when you know the prefix of a name and want to construct a new nanr^ using 
either the pref be or suffix of the same name. It is probably most useful for extracting the first component or 
the last component of a composite name. 
Get Suffix 

compositeZname_tget_,suffbc( IN composite_name_t cname. IN composlte_nameJ pname) 
Usage: whats Jef t = get_suf f bc( whole_name, pref ix_of ) ^ ^ 

Returns the ordered subsequence of components from "cname" that do not appear in pname if 
"pname" is prefix of "cname". 

Operation fails if "pname** is not a pref be of "cname". 
This procedure is useful in caching, for example, where we may want to determine whether there is cached 
information about prefixes of a composite name, or the whole composite name. 
Copy 

composite_name_t copy( IN composite_name_t cname ); 
Usage: new_name = copy( cname ); 
Returns a copy of the given composite name "cname". 
Free 

free( IN composite_name_t cname ); 
Usage: free( cname ); 
Release the storage used to hold "cname". 
A Naming System that wishes to join the Open Federation federation must adhere to the CompositK)n syn- 
tax described above. The Naming System must also provide operattons similar to those defined above for 
"Equivalent", "Count_Components^ "Concatenate". -Split". "Get„Suffix-. "Copy-, and "Free" 

Using this Composition Syntax and the related operations, the standard Naming Interface for Contexts in 
the preferred embodiment OpenFederation is now described. 

The OpenFederation Naming Interface 

In the preferred embodiment OpenFederation defines a context interface that includes the-OpenLookUp". 
-OpenBind", "OpenUnbind". and "OpenUst" operattons. The interface syntax and semantics are descnbed as 
follows. 

Interface Definition ^ ^. ^ x i. 

The "interface definition" in the present embodiment, in terms of pseudocode, is defined as follows: 
typedef string<unbounded> Composite Name; 
const Name NULLNAME=<0>; 

typedef sequence <Composite Name.UNBOUNDED> NameUst; 
const int BIND_SUPERSEDE=0x1 
interface Context { 
typedef enum ( * 

OK NOT_CONTEXT. NOT.FOUND, NO_PERMISSION, 
ALi=iEADY_BOUND, ILLEGAL_NAME. UNSUPPORTED__OP 
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) statuscode; 
typedef struct { 

statuscode err; 

Composite Name where, rest; 
5 objref_t ref; 

boolean precisely; 
} status; 

objref_t OpenLookup( in Composite Name name, out status* ); 
void OpenBind( in Composite Name name, in objreM objref. In int flags, out status* ); 
10 void OpenUnbind( in Composite Name name, out status* ); 

NameList OpenUst( in Composite Name name, out status* ); 

}: 

Requirements 

In the preferred embodiment, every OpenFederation Context must provide full support for the "OpenLook- 
15 up" operation that we describe below. It need not support the "OpenBind", "OpenUnbind", and "OpenList" op- 
erations to the extent described. In the case that a terminal context does not support the desired operation, 
it must return the status code '•UNSUPPORTED_OP" and the remaining status information, as described be- 
low. 

Names 

20 In the preferred embodiment, all of the operations supported by OpenFederation Context objects take 

Composite Names as arguments. A composite name is interpreted relative to the context object on which the 
operation is invoked. 

The use of "NULLNAME" as a name has a special interpretation. When supplied to a context object, it is 
a name for that context itself. 
25 In all of the following, "ctx" is an OpenFederation context object. In the preferred embodiment, the following 

are the required operations. 
Lookup 

Usage: objref = ctx->OpenLookup(name, &status); 

returns a reference to the object named by the Composite Name "name" relative to the context "ctx". 
30 If "name" is equal to "NULLISIAME", "OpenLookup" returns an object reference to the object "ctx". 
Bind 

Usage: ctx->OpenBind(name, objref, flags, &status); 

binds the terminal atomic part of the supplied Name "name" to the supplied object reference. The bind- 
ing is made in the penultimate context in "name", relative to "ctx". If "name" is Atomic, the binding is done in 
35 the context "cU". 

Unless the "BIND_SUPERSEDE" flag is set, the binding must be exclusive. That is, the operation returns an 
error code in "status" (see the section "Status Information" below) and the operation fails if the terminal Atomic 
part of the provided Name is already bound. If the "BIND_SUPERSEDE" flag is set, then the bind operation 
will overwrite any existing binding. 
40 Unbind 

Usage: ctx->OpenUnbind(name,&status); 

removes the binding of the terminal Atomic part of "name" from the penultimate context of "name" rel- 
ative to "ctx". 

List 

45 Usage: listing = ctx->OpenList(name.&status); 

returns a list (of type "NameList") of ail of the names that are bound in the context named by "name" 
taken relative to "ctx". 

Status Information 

50 

In the preferred embodiment of the federation OpenFederation, Status Information is handled in the fol- 
lowing manner. 

Status Structure 

Each of the operattons returns a parameter "status", which is a structure (i.e. a set of data). The field "sta- 
55 tus.err" contains a "status code" of type "statuscode". The interpretation of the remainder of the status structure 
depends on this status code. Except in those cases specified differently below, the interpretation is as follows: 
"status.where" contains the name of an intermediate context up to which the operation proceeded normally. 
(The name in "status.where" is interpreted relative to the "returning" context That is, if a context "ctx" obtains 
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the status information from a lower-level context service, then "ctx" must revise "status-where" so that it names 
the same object relative to "cU".) The field "status.ref will always be an object reference to the context named 
by "status where-; -status.resf will contain a name, which relative to "status.where" is equivalent to the input 
name If the boolean field "status.piBcisely" is true, then the returning context guarantees that -status.where" 
names precisely the context in which an error occurred. If-status.precisely"isfalse. the returning context guar- 
antees only that "status-where" names an intermediate context up to which no error occurred during that op- 
eration, but not necessarily the context in which the error occurred. 
Status Codes 

In the preferred embodiment, the following Status Codes are defined: 

-OK° - the operation succeeded. For all operations except "OpenList-, "status.where" will contain the 
penultimate prefix of "name", (so 'status.rest" will contain the terminal atomic part of the input parameter 
-name"). For the "OpenLlst" operation, "status.where" will be the entire "name", and "status-resf will be NULL- 
NAME". For all operations "status.precisely" wfll always be "true" on an "OK" return. 

"NO_PERMISSION" ~ permission was not granted for some required operation either at a terminal or 

intermediate context . . i • ^. m 

"ALREADY_BOUND" - (this code applies to the operation "bind" only), the terminal atomic name had 

an existing binding in the penultimate context, and the -BIND_SUPERSEDE" flag was not set 

•NOT_CONTEX-r ~ either the OpenUst operation was invoked on an object that was not a context or 

the resolution of the supplied name reached a non-context object before reaching the penultimate context 
•NOT FOUND- - the terminal atomic name was not bound in the penultimate context or resolution 

could not proceed beyond some Intermediate context because the next atomic name requiring resolution was 

not bound. . , ... _„„ 

-|LLEGAL_NAME* - some component of the name was not a well-formed name in the assoaated nani- 

ing ^^^^^'JJJg^jppQp.^gp Qp. ji^g operation invoked was not supported by the terminal context. This can 
happen on "OpenBind". "OpenUnbind", and "OpenLisf operations. As indicated above, all federation members, 
by definition must support the ComposileLookup operation (in the preferred embodiment "openLookUp"). but 
may choose not to support the operations of "openBind". "openUnbind", and "openUst". If they do not support 
these operations, then this Status Code wouW be returned whenever one of those operabons is invoked. In 
the preferred embodiment all of these operations are implemented. 

Exceptions ui » ». 

In the preferred embodiment, an openFederation context may raise an exceptfon if it is unable to return 
normally with a status described accurately by one of the status codes. Normally these exceptions would be 
masked by intermediate OpenFederation contexts before reaching a caller outside the OpenFederation fed- 
eration It is therefore required that federation membera have a minimal recovery procedure that every feder- 
ation context must follow before allowing an exception to proceed to its immediate caller. In the preferred em- 
bodiment, every OpenFederation context must follow such a minimal recovery procedure before allowing an 
exception to proceed to its immediate caller, upon receipt of. for example, the foltowing status code:. 
" FAILURE" ~ an unexpected failure prevented normal return. 

As can beseen from the above descriptfonof the preferred embodimentofafederationof disparate naming 
systems, the minimal requirements for joining a similar federatton include: 

1 An agreement on the general definition of a Composite Name syntax for use by the federation. The com- 
posite name will be a sequence of one or more names, n,. n^from possibly disparate Naming Systems. 

The preferred Composition syntax is as described above fbrthe OpenFederation embodiment Other com- 
position rules may be used which are equivalent 

2 Aset of operating means for performing the function of Composite Name lookup at a minimum. It is also 
suggested that the operations of binding, unbinding, and listing names also be implemented. 

From the above it can be seen that new membere can be added to the federation without impact to the 
existing members. That is. adding a new Naming System to an existing Federation only requires that a refter- 
ence to a Context In the new Naming System be bound to a Name in a Context in one or more of the prior 
member Naming Systems. ^ . ^ . j »u 

Thus it can be seen that in such a system any number of disparate naming systenre may be federated with 
minimal implementation cost to the individual systems and clients, and that no intermediate customized agents 
or gateways are required, resulting in better performance and fewer fault-tolerance issues. 

As this invention may be embodied in several forms without departing from the spirit of the essential char- 
acteristics thereof, the present embodiment is therefore illustrative and not restrictive, since the scope of the 
invention is defined by the appended claims rather than by the description preceding them, and all changes 
that fall within the metes and bounds thereof are therefore intended to be embraced by the daims. 
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Claims 

1. In a distributed computing environment an apparatus for a federated naming system which can resolve 
a composite name composed of any number of disparate naming systenris comprising: 

a) a set of naming systems; 

b) a set of objects contained in each of said naming systems; 

c) a syntactic means for combining names from said naming systems into a composite name; and 

d) an operation means for resolving the composite names. 

2. The apparatus defined in claim 1 wherein the naming system comprises: 

a) a naming convention which specifies names and atomic names; 

b) a parsing means for providing the head name and the tall name related to said names; 

c) a set of context objects each of which is a set of bindings of said atomic names to object references; 
and 

d) an operating means for performing the functions of name lookup, making use of said parsing means. 

3. The apparatus defined in claim 1 wherein the syntactic means for combining names into a composite name 
comprises: 

a) a sequence of one or more names from possibly different naming systems; and 

b) a means for ordering the sequence of names. 

4. The apparatus defined in claim 1 wherein the operation means for resolving the composite name conrv 
prises a composite look-up device which will provide: either an object reference if the composite name is 
an atomic name; or wilt provide a reference to a context object in another naming system and the tail of 
the composite name, if the composite name refers to a context object in another naming system; or will 
provide the tail of the composite name within the naming system. 

5. The apparatus defined in claim 4 which comprises the additional operations of composite name binding, 
unbinding, and listing names. 

6. The apparatus defined in claim 5 wherein the apparatus operates within object-based distributed com- 
puting environments. 

7. In a distributed computing environment, a method for a federated naming system which can resolve a com- 
posite name composed of any numt^r of disparate naming systems comprising the steps of: 

a) specifying a set of naming systems; 

b) defining a set of objects contained in each of said naming systems; 

c) specifying a syntax for combining nanr^s from said naming systems into a composite name; and 

d) resolving said composite names. 

8. The method described in daim 7 wherein the step of specifying a naming system for each member of the 
federation comprises the steps of 

a) specifying a naming convention which defines names and atomic names for the said naming sys- 
tems; 

b) establishing parsing operations for providing head name and tail name components related to nanr^s 
from said naming systems: 

c) defining a set of context objects each of which is a set of bindings of said atomic names to object 
references; and 

d) operatively related to said parsing operations, establishing resolving operations for performing the 
operation of name lookup. 

9. The method described in daim 7 wherein the step of combining any number of names Into a composite 
name comprises the steps of 

a) ordering in a specified manner sakj names into a sequence of said names; 

b) providing operations which can break said sequences of names into their component parts; and 

c) providing operations which can compose component parts Into said composite names. 

1 0. The method described in daim 7 wherein the step of resolving the composite names comprises the steps 
of establishing a composite lookup operation which will provide: either an object reference if the composite 
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name is an atomic name; or will provide a reference to another naming system context and the toil of he 
compiii nlme. if the Composite name refers to another naming system; or w^^^^^^ the taO of the 
composite name within the naming system context of the original composite name. 
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